From: Paul Eggert <eggert@cs.ucla.edu>
Date: Sun, 23 Jun 2024 00:42:04 +0000 (-0400)
Subject: Fix FIXME in comment
X-Git-Tag: archive/raspbian/1%30.1+1-3+rpi1^2~14^2~18^2~923
X-Git-Url: https://dgit.raspbian.org/%22http://www.example.com/cgi/%22/%22http:/www.example.com/cgi/%22?a=commitdiff_plain;h=2b848a4e504319cce150000a2c3855f66d89714b;p=emacs.git

Fix FIXME in comment

* src/timefns.c (decode_float_time): Explain why the code
can use large precision here, removing a FIXME by updating
the containing comment.
---

diff --git a/src/timefns.c b/src/timefns.c
index 0ecbb6e6793..746e422ffb6 100644
--- a/src/timefns.c
+++ b/src/timefns.c
@@ -414,9 +414,11 @@ decode_float_time (double t, struct lisp_time *result)
   else
     {
       int scale = double_integer_scale (t);
-      /* FIXME: `double_integer_scale` often returns values that are
-         "pessimistic" (i.e. larger than necessary), so 3.5 gets converted
-         to (7881299347898368 . 2251799813685248) rather than (7 . 2).
+      /* Because SCALE treats trailing zeros in T as significant,
+	 on typical platforms with IEEE floating point
+	 (time-convert 3.5 t) yields (7881299347898368 . 2251799813685248),
+	 a precision of 2**-51 s, not (7 . 2), a precision of 0.5 s.
+	 Although numerically correct, this generates largish integers.
          On 64bit systems, this should not matter very much, tho.  */
       eassume (scale < flt_radix_power_size);